Subject: Comments on the flow control proposal.

From: Nagi Swaminathan <[email-masked]>
Date: Mon, 7 Mar 94 14:47:58 EST

Peter,

Your flow control proposal looks great. I have two comments on the
proposal.

1. I do not know much about how APPN uses the adaptive pacing. But, in the
   adaptive pacing scheme used in Virtual Route pacing control, the receiver
   of the pacing response increments the window only if the pacing response
   is not received before sending the current window and it has to wait for the
   pacing response before sending the next window. Each time such a thing
   happens the window size is incremented by one, of course bounded by the
   maximum size. 
   I suggest using a similar scheme. That is sender will increment the window
   only if the pacing response is not received in time. 
   In addition, to keep  the receiver control over the window size at any
   time, the sender can maintain a maximum send window size variable which 
   will get incremented every time an  IPM with IWI bit set is received. This 
   variable will also be set to 0 if an IPM with RWI bit set is received or
   halved if an IPM with HWI bit set is received.

   The sender will increment the window if the pacing response is not received
   in time but in no case will it increment this beyond the current value of
   maximum window size.
   
   Employing this scheme will prevent the window size from
   growing beyond what is necessary and will not result in too many
   large windows open when congestion happens. The receiver will know at any 
   given time  the maximum allowable window size, but the actual window size 
   used by the sender may be smaller than this. 

   As an additional note I should add that this can not be used if this aspect
   of flow control is patented by IBM. I am not sure whether this scheme was 
   considered earlier and dropped due to patent issues. If that is the case, 
   please ignore this  comment.

2. Most of the implementations will not issue any reads to the TCP 
   connection when the buffers are low. This will result in traffic
   in the other direction also being stopped as the required pacing response
   will be queued within the TCP. This will also mean the IPM with RWI and HWI
   may not take effect immediately. This problem has been raised in the
   RIG meeting and the only solution is to  have two TCP connections.
   Of course, adding one more TCP connection will not come free and will
   have its own set of problems with respect to connection management.  
     
Regards..

Nagi.